Object-oriented software languages are an attempt to mirror the real world, in the sense that “physical” Objects are identified, and certain functionality is associated with each given Object. Software Objects are not easily portable, so it is common to convert software Objects to markup language code for transmission over the Internet, re-assembling the Objects when they are received. In fact, a number of protocols have been developed to support the communication of XML data over the Internet. It is therefore much easier to transmit database queries and structures, for example, over the Internet using XML (eXtensible Markup Language) code rather than Java Objects.
XML is a standard, software development language-independent text format for representing data. XML is a markup language in the same sense as Standard Generalized Markup Language (SGML), and Hyper Text Markup Language (HTML), This paradigm allows XML to facilitate communication between disparate systems—as long as all of the parties involved understand the particular XML model, the nature of the model itself is irrelevant and independent of the platforms involved.
This universal “understanding” of XML documents is facilitated by the use of XML schema. A set of syntax rules for XML elements shared by a group of XML documents is defined by an XML schema, which is an XML document itself. The syntax rules may, for example, indicate what elements can be used in a document, define the order in which they should appear, define which elements have attributes and what those attributes are, and identify any restrictions on the type of data or number of occurrences of an element. Schemas can be custom designed, though many schema are established by standards groups for general areas of application.
Two specific advantages of XML in the handling and transmission of Object-oriented software systems over Internet networks are:                1. Configuration: XML documents are a common way of storing configuration information—for example, EJB (Enterprise Java Beans) deployment descriptions and WSDL (Web Services Description Language) files that describe web services, are both in XML format. Object-XML conversion technologies allow a developer to interact with the data as recognizable domain Objects instead of having to use XML specific APIs and data structures; and        2. Persistence: It is easier to store XML documents than Objects. XML documents can either be stored directly to something like a file, to an EIS (Enterprise Integration Systems) data store that accepts XML records, or to an XML database.        
Converting back and forth between XML and software Objects is not a trivial task. While XML represents data as a plain text document composed of a series of elements in a hierarchical format, software Objects in an Object-oriented application are composed of a complex set of data-types, pointers, application rules/methods, inheritance and relationships to other Objects. It is not surprising that the attempts at tools which can convert between software Objects and XML, have not been particularly effective. Two such families of tools include “Direct Converters” and “Code Generators”.
Direct Converters
One family of Object-XML conversion tools are known as “direct converters”. This family includes, for example: “XStream”, the details of which may be found on the Internet at http://xstream.codehaus.org/ and “betwixt” which may be found at http://jakarta.apache.org/commons/betwixt/. These tools employ a fixed set of rules determining how an Object is converted to and from XML.
A first example of how an Object could be converted to an XML format using a direct converter is presented in FIG. 1. In this example the Class names and attribute names in the Java class become the element names in the resulting XML document (different direct converters may have different algorithms, but this is the general approach). The attribute “firstName” with value “Jane” in the Object 12, becomes a line of XML code in the XML document 14 reading “<firstName>Jane</firstName>”. Similarly, the secondName attribute with value “Doe” becomes a line of XML code reading “<secondName>Doe</secondName>”. The city and street data are similarly transposed from the Address Object to the XML document.
If the Object model is changed as shown in the second direct converter example, presented in FIG. 2, then a different XML document will be produced. In this case, the name of the “city” attribute of FIG. 1 has been changed to “town”. This “town” attribute will be converted to a line of XML code reading <town>Some Town</town> rather than <city>Some Town</city> as in FIG. 1.
Using direct conversion tools, the XML document will reflect the structure of whatever Java Objects happen to arrive. Thus, there is no guarantee that an arriving document will conform to a given XML Schema.
In the third example of direct converters, presented in FIG. 3, the “city” attribute in the “Address” class was renamed to “town”. If the XML document does not conform to the rules necessary to convert it to the Object then it cannot be converted using a direct conversion tool. A direct converter solution is only useful if you do not care how the XML data is formed—in this third example the “town” element cannot be converted to the “city” attribute in the “Address” class.
Generally, one does care how XML and Object data are transformed, so direct conversion techniques are of very limited usefulness.
Code Generators
A second family of Object-XML conversion tools is referred to as “code generated solutions”. Code generated solutions take an XML Schema or some other XML document structure definition such as a DTD (document type definition) and produce an Object model from that. The advantage of this approach over data converters is that the resulting document will conform to the XML Schema. Two examples of “code generators” are JAXB which is described on the Internet at http://Java.sun.com/xml/jaxb/index.jsp, and BEA XML Beans which is described at http://dev2dev.bea.com/technologies/xmlbeans/index.jsp.
For example, assume that the following XML schema is given to generate an Object model:
<?xml version=“1.0” encoding=“UTF-8”?><xs:schema xmlns:xs=“http://www.w3.org/2001/XMLSchema” elementFormDefault=“qualified” attributeFormDefault=“unqualified”> <xs:element name=“employee”>  <xs:complexType>   <xs:sequence>    <xs:element ref=“personal-info”/>   </xs:sequence>  </xs:complexType> </xs:element> <xs:element name=“personal-info”>  <xs:complexType>   <xs:sequence>    <xs:element name=“first-name” type=“xs:string”/>    <xs:element name=“last-name” type=“xs:string”/>   </xs:sequence>  </xs:complexType> </xs:element></xs:schema>Then something similar to the following will be generated by code generated solutions:

The key point is that a “PersonalInfo” class is generated by a code generated approach. This does not follow with object-oriented programming since an “Employee” object with attributes “firstName” and “lastName” is required to model the data. In fact, code generated solutions do not allow any control over the nature of the Objects which are generated. Hence, code generation tools are useful when you care about the XML schema but not about the Object model.
“Code generator” Object to XML conversion tools can only infer very limited meaning on the structures that they encounter in the XML document. For example, they typically generate a separate Object for each XML element, nesting these Objects within one another as required by the XML structure. As well, the existing tools do not appreciate that some XML elements contain data while others are used to organize data. This results in a complicated, cumbersome Object structure which does not reflect what is desired or what is intuitive to the user.
A more powerful family of XML to Object conversion tools have been evolving, referred to as “mapping” tools. These tools allow the user to manually define how the XML and Objects are to be converted back and forth. However, the existing mapping tools are deficient in a number of ways.
In particular, these mapping tools (along with the direct converters and code generators which preceded them) convert between XML and Objects in a way that is independent of paths and structures. These tools arbitrarily generate separate Objects for each level of nesting that is encountered, without regard for the fact that some XML elements contain data, while others are used solely to organize data.
It is therefore desirable to provide a method and system for converting data between Object-oriented classes and markup languages which takes the paths and structures of the markup language and software Objects into consideration. This solution should be provided with consideration for the problems described above.